The Internet is composed of content distributed in the World Wide Web and various intranets. While a large fraction of the content is static, the truly interesting content is the one that a user can interact with dynamically. This content is of various types including, but not limited to (i) the content stored in various databases, (ii) e-commerce web-pages, (iii) directories, (iv) intranet pages, (v) data warehouses, etc.
The interaction with this dynamic content is accomplished through (i) queries/submissions to databases, (ii) buying/selling/interacting through e-commerce, (iii) running queries and lookups in directories, (iv) accessing and interacting with content resident on intranet pages (including on individual computers), and/or (v) accessing, interacting with, adding, subtracting or modifying content resident in data warehouses.
The access to or interaction with this dynamic content is done in a variety of ways. For example, such interaction may be accomplished through direct access to the databases by running specific commands or through form submissions on the Internet that run specific queries or perform specific actions. This interaction requires the submission of necessary parameters or information to complete a query or interaction (addition, modification, subtraction) with the dynamic content. This information may need to be submitted in multiple steps. Once the submission of information is finished, the results of the interaction/query/e-commerce are sent back to the user.
Each time a user wishes to interact in the foregoing manner, the user is required to carry out each and every one of the steps associated with the submission of necessary parameters or information. If a same type of transaction is to be carried out in a repeated manner, this may be very time consuming and problematic. Moreover, being able to fetch various content items from Java applets in an automated fashion is valuable in and of itself. It enables data that has thus been fetched by the system in the background to be processed in various ways. For example, an alert could be set on financial information aggregated from a commercial web site in this manner. That data could also, for example, be used in various financial calculations and transactions.
Accordingly, accessing web content is more complicated than simply making individual HTTP requests. The prior art has yet to enable fetching of the same content as the user and rendering it the same way the user saw it. To do this, the appropriate content must be fetched across the network. It must then be rendered correctly. An additional step comes even before these. First, the content must exist for it to be fetched. It sometimes will just pop up on the page on its own, but typically one must perform some actions (firing Java events) to cause it to be created. For instance, HTTP actions as well as Java and Javascript events must be fired.
When fetching the content, the user may first be required to log in, run a search for a certain term, or fire an event. More generally, the content of interest could be generated by an arbitrary web transaction. Logging in and running a search are all examples of web transactions. Thus, fetching content requires support for various authentication and network protocols, management of client-side state information, support for the appropriate cipher strength, and/or be able to fire events.
It should be noted that fetching any interactive web content requires the ability to be able to execute web transactions. In the case of non-interactive content (e.g. the top headlines from a news site), no transaction is required to retrieve the content. One simply has to request the page from the remote server. However, if any interaction is required to access that content (e.g. weather report for a particular zip code), the transaction must be executed before the content can be retrieved.
Web transactions vary in their complexity. They may be as simple as entering a zip code to receive a customized weather report. On the other hand, they may be complex enough to involve logging in to a secure stock trading site, browsing to a particular page on the site, submitting a query and then browsing to a specific section in the report to obtain the current credit rating of a company.
Interaction with Java applets poses a particularly challenging problem. The question posed is how does one integrate the applet with background functionalities to automatically take data out of the applet so that it can be used or have functions applied to it.
To apply functionality to the data, the data must be retrieved from the applet. Prior to the present invention, it was not possible to create an application with the ability to interact with an uncooperative third-party Java applet to extract data from it. This is particularly true of applets running in a security context in a browser, where the applet does not have access to data and programs on the computer outside of the browser, and outside programs or other applets cannot access the applet if they do not share the same security domain.
The reason no one has been able to solve the problem is that, because of the way current browsers like Microsoft Internet Explorer and Netscape Navigator are coded, the application trying to access the applet must come from the same source as the Java applet. For example, a JavaScript piece of code and a Java applet on the same page would both have to know how to communicate with each other and how to exchange the data. The JavaScript would need to know what methods to call the Java object, what those methods represented, what the data is when it is returned by the method, etc. If they were not from the same domain, this interaction would not be possible at all.
Thus, what is needed is a way to overcome the limitations of the prior art and allow extraction of data from a Java applet.